Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

task -set blend tolerance default based on machine units #1853

Closed
wants to merge 3 commits into from

Conversation

c-morley
Copy link
Collaborator

A very common newbee complaint is huge corner rounding.
This is caused by linuxcnc setting the default blend tolerance to maximum.
Now we set it to a (seemingly) reasonable default depending if the machine
is metric or inch.

A very common newbee complaint is huge corner rounding.
This is caused by linuxcnc setting the default blend tolerance to maximum.
Now we set it to a (seemingly) reasonable default depending if the machine
is metric or inch.
@petterreinholdtsen
Copy link
Collaborator

This change cause tests in the test suite to fail. To see the errors yourself, run 'scripts/runtests tests/' after a local build. I guess, either the tests need to be modified, or the change need to be disabled by default.

@hansu
Copy link
Member

hansu commented Jul 20, 2022

Is there anything against having an even value if the units are mm? So 0.01 instead of 0.0254.

@petterreinholdtsen
Copy link
Collaborator

petterreinholdtsen commented Jul 20, 2022 via email

@c-morley
Copy link
Collaborator Author

Yes I forgot to run the tests locally. I will fix the tests soon.
Yes I picked .0254 as equivalent. Could round it to .03 or something close. Whats a good value?

@hansu
Copy link
Member

hansu commented Jul 20, 2022

The question is if it has to be equivalent. A value like 0.0254 as precision makes not much sense when not knowing that its derived from inches.

Furthermore I think 0.01 is also a good value for hobby machines as it is only the reference value. Position error has to be added to that.

@c-morley
Copy link
Collaborator Author

You think metric should be 3 times tighter then imperial by default?
It may even be that .0001 and .00254 would be useable - I just found .001 (inch) in the forums.

In reality the number should be small enough that it doesn't matter if it's an oddish number.
and if it does matter then it should be set by the gcode.

@samcoinc
Copy link
Collaborator

samcoinc commented Jul 20, 2022 via email

@samcoinc
Copy link
Collaborator

samcoinc commented Jul 20, 2022 via email

@c-morley
Copy link
Collaborator Author

From my reading of the forum, it was suggested that a very small setting was still suffient to get reasonable corner speed. Have you done real world testing?
To be clear i am definitely preferring path following to speed as a default.

@samcoinc
Copy link
Collaborator

samcoinc commented Jul 20, 2022 via email

@c-morley
Copy link
Collaborator Author

c-morley commented Jul 20, 2022

I Remember u embarrassing Mach 3 :) could u try your test with .0001 setting and see the time difference?

@c-morley
Copy link
Collaborator Author

Or sorry u did .01 mm ok I think that tells us what we need. Thanks

@samcoinc
Copy link
Collaborator

samcoinc commented Jul 20, 2022 via email

@petterreinholdtsen
Copy link
Collaborator

I did a ton of trajectory planner testing a long time ago.. ;)

How did you do this testing? Can it be scripted and perhaps added to the tests/ collection?

if (canon.lengthUnits == CANON_UNITS_INCHES) {
SET_MOTION_CONTROL_MODE(CANON_CONTINUOUS, .001);
} else {
SET_MOTION_CONTROL_MODE(CANON_CONTINUOUS, .0254);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the code intent is expressed more clearly if you use something like .001 * MM_PER_INCH instead of .0254? The compiler will end up with the same value, so there will be no speed impact, but it will be more obvious that the intent is to use the same tolerance independent of units.

@petterreinholdtsen
Copy link
Collaborator

petterreinholdtsen commented Jul 22, 2022 via email

@samcoinc
Copy link
Collaborator

samcoinc commented Jul 22, 2022 via email

@petterreinholdtsen
Copy link
Collaborator

petterreinholdtsen commented Jul 22, 2022 via email

@c-morley
Copy link
Collaborator Author

Operation with tolerance 0.1 took 20 seconds
Operation with tolerance 1 took 20 seconds
Operation with tolerance 0.01 took 20 seconds
Operation with tolerance 0.001 took 20 seconds
Operation with tolerance 0 took 20 seconds

try it compared to g61
This seems to show that a very small value is sufficient for a good speed up.
There are also other setting to optimize:
http://linuxcnc.org/docs/devel/html/config/ini-config.html#sub:ini:sec:traj

A program with many short segments would show blending better (more time in acceleration phase rather then cruise phase)
Your test program should show the path deviation though.

@petterreinholdtsen
Copy link
Collaborator

petterreinholdtsen commented Jul 23, 2022 via email

@silopolis
Copy link
Contributor

silopolis commented Jul 23, 2022 via email

@c-morley
Copy link
Collaborator Author

it's more of a program tuning code. Machine can only do what the hardware will let it.

@c-morley
Copy link
Collaborator Author

thanks for your help to make this better. merged

@c-morley c-morley closed this Jul 28, 2022
@c-morley c-morley deleted the cmorley/default_blend_tolerance branch July 28, 2022 02:35
@petterreinholdtsen
Copy link
Collaborator

petterreinholdtsen commented Oct 11, 2022 via email

@andypugh
Copy link
Collaborator

It will probably depend on the accelleration limits of the machine. Were you testing in a simulator? What were the acceleration limits?

@c-morley
Copy link
Collaborator Author

Have you been looking for path deviation as well as speed up?
Less path deviation is the main idea of the patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants